With the emergence of 3G mobile telephony, new packet-based communication technologies have been developed to support multimedia communication. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video files, etc., in addition to traditional circuit-switched voice calls.
Multimedia services typically entail transmission of encoded data representing text, documents, images, audio files and video files in different formats and combinations. The term “multimedia” will be used in this description as generally referring to any choice of media communicated by using the packet based IP (Internet Protocol) transport technology.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard for handling multimedia services and sessions in the packet domain. IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used, and is neither restricted to any specific services. Thus, IMS networks are used for controlling multimedia sessions by acting as a “control plane” for the sessions, whereas the actual transfer of payload data is typically routed over access networks and any intermediate transport networks, although nodes in the IMS network may also be used.
FIG. 1 is a simplified schematic illustration of a basic network structure for providing multimedia services by means of an IMS service network. A first mobile terminal A is connected to a first radio access network 100 and communicates with a second mobile terminal B connected to a second radio access network 102, in a communication session S involving one or more multimedia services. There may also be an intermediate backbone network, not shown, as well linking the access networks 100 and 102.
An IMS network 104 is connected to the first radio access network 100 and handles the session with respect to terminal A. In this figure, a corresponding IMS network 106 handles the session on behalf of terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Alternatively, terminals A and B may of course be connected to the same access network and/or may belong to the same IMS network. Terminal A may also communicate with a fixed terminal or computer or server instead, e.g. for downloading some media over the Internet, as long as the other party is capable of SIP communication. Moreover, if a terminal is roaming in a visited access network, multimedia services are handled by the terminal's “home” IMS network.
The session S shown in FIG. 1 is managed by specific nodes in each IMS network, here generally referred to as “session managing nodes” 108. These nodes typically include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). Each IMS network 104,106 also includes one or more application servers 110 for enabling various multimedia services. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things. IMS network 106 is basically similar to network 104. The various specific functions of the shown network elements 108-112 are generally known in the art, but are not necessary to describe here further to understand the context of the present invention. Of course, the IMS networks 104,106 contain numerous other nodes and functions not shown here for the sake of simplicity.
A specification for handling sessions in IMS networks has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261). SIP is an application-layer control protocol for signalling, to create and generally handle sessions over a packet-switched logic. The SIP standard is thus used by IMS systems and SIP-enabled terminals to establish and control IP multimedia communications. SIP itself does not provide multimedia services, but rather makes available a set of primitives that other protocols or applications can use to actually implement such services. For example, a message called “INVITE” is defined in SIP to initiate multimedia sessions. The SIP INVITE message includes, among other things, information on what application server to invoke during session set-up, a nickname and SIP URI (Universal Resource Identifier) of the calling party, the SIP URI of the called party, and other communication parameters needed for the forthcoming session.
SIP uses an additional protocol called Session Description Protocol, SDP, for describing the media content to be transferred in multimedia sessions. An SDP message can be embedded as a self-contained body within SIP messages. SDP messages can be used by terminals to exchange information regarding their specific capabilities and preferences, in order to negotiate and agree on which session parameters, codecs in particular, to use during a forthcoming multimedia session, as is well-known in the art.
Many mobile applications require a certain Quality of Service QoS in order to provide a satisfying result to end-users. For UMTS networks, four main QoS traffic classes have been defined: “conversational class”, “streaming class”, “interactive class” and “background class”, in order to classify different needs regarding bitrates and delays. These classes are primarily distinguished by their requirements regarding transfer delays, such that applications of the conversational class tolerate only small delays, sometimes also referred to as “real-time”, whereas the background class is applied to the least delay-sensitive applications, sometimes also referred to as “best effort”.
The selection of a UMTS QoS traffic class for an application is used for assigning a suitable Radio Access Bearer RAB in the access network, including a radio channel, in order to optimise the scarce radio recourses in the access network whilst maintaining acceptable quality for the end-user.
Mobile terminals capable of multimedia are typically configured to identify for each inherent application, a UMTS QoS traffic class, as schematically illustrated in FIG. 2. Thus, a mobile terminal may hold a number of applications 200, denoted as A1, A2, A3, A4, A5 . . . . A mapping function 202 in the terminal translates each application to a certain UMTS QoS traffic class 204, of which only two are shown here. In this case, applications A1, A2 and A4 are mapped to the same UMTS QoS traffic class 2, since they have similar requirements regarding bitrate and delay, whereas applications A3 and A5 are mapped to UMTS QoS traffic class 1. In this way, several applications with similar characteristics may be mapped onto the same RAB, fulfilling their requirements.
However, before a mobile terminal can exchange any SIP messages with the IMS network, a “PDP context” must be established for the terminal. Basically, a PDP context can be activated once the terminal has been powered on. Activating a PDP context for a mobile terminal includes allocating an IP address to the terminal, to be able to communicate data packets with the terminal. A PDP context also means that an RAB is allocated in the access network for IP communication. Thus, SIP messages can only be sent over a PDP context.
FIG. 3 illustrates the gradual activation of a mobile terminal A about to communicate multimedia with another party, involving basically five stages 3:1-3:5 as illustrated, each comprising various messages back and forth. These messages are well-known in the art and will not be described in any detail. Terminal A is located under radio coverage of a mobile access network 300, which is divided into a radio network part 300a and a core network part 300b including the nodes SGSN (Serving GPRS Switching Node), HLR (Home Location Register) and GGSN (Gateway GPRS Switching Node), among other things. The other party may be another mobile terminal B connected to a mobile access network 302, or a fixed telephone or computer, or a server connected to the Internet 304.
In a first stage 3:1, when terminal A is powered on, it is registered as a connected “Mobile Station MS” with the access network 300, for circuit-switched communication. SGSN and HLR in core network 300b are involved in this initial stage of establishing a radio connection for attaching the terminal.
Next, a first PDP context, referred to as “primary”, is activated in a stage 3:2, to obtain an IP connection. Activating the primary PDP context includes obtaining a RAB for packet-switched SIP signalling messages over IP. The PDP context is created by GGSN in network 300b. This RAB is typically based on so-called “best effort” communication with no particular requirements regarding bitrate and delay, since it is only intended to occasionally carry relatively short SIP messages. Furthermore, the RAB characteristics of a primary PDP context may fluctuate depending on variations in available capacity and bandwidth in the access network. “Best effort” means basically that any available radio resources and bandwidth not needed for other connections with higher priority, can be used. Thus, the primary PDP context is adapted for signalling messages.
In a third stage 3:3, terminal A registers with the IMS network 306, as basically handled by an S-CSCF node and HSS therein, as illustrated. The IMS registration involves a certain amount of SIP-based signalling over the primary PDP context.
Next, a multimedia session is to be established with another party in a following stage 3:4. In this stage, the above-mentioned protocol SDP is used within the SIP messages, such as INVITE, to communicate session-specific parameters including codecs. The following UMTS parameters may be derived from the SDP message: Traffic class, Maximum bitrate (uplink/downlink), Guaranteed bitrate (uplink/downlink), Transfer delay (uplink/downlink), Delivery order, Maximum SDU (Service Data Unit) size and a Source Statistic Descriptor.
In a next stage 3:5, a secondary PDP context is activated for terminal A, and should be adapted for the media type(s) involved in the forthcoming session. The secondary PDP context is handled by GGSN in the same manner as for the primary PDP context in stage 3:2. Thus, the secondary PDP context should be defined so as to fulfil the requirements of the session with respect to the SDP information as well as other factors, in order to obtain a proper RAB for media to be communicated. The new RAB is thus more stable and reliable as compared to the first one associated with the primary PDP context.
Activating the secondary PDP context according to stage 3:5 is a somewhat time-consuming process. It should be noted that, if the other party is an IMS enabled mobile terminal B, a corresponding process takes place on the other side for that terminal as well. When the secondary PDP context has finally been activated, the session can start as illustrated in a stage 3:6, using the allocated new RAB.
The communication of media is thus delayed by waiting for the secondary PDP context to be activated and a corresponding RAB to be allocated, according to conventional set-up procedures for multimedia sessions. In the field of mobile communication, it is generally desirable to minimise such delays in order to make multimedia services more attractive to mobile end-users. It is also desirable to reduce the complexity and general amount of signalling in the session set-up procedure. In mobile networks, it is further generally desirable to avoid excessive occupation of bandwidth in the air interface due to scarce radio resources.